feat: make the provider request path observable - #2873

Description

The v2 provider's request path is effectively silent. Compared to v1, an operator gets almost nothing to debug with:

Two concrete holes:

• A failed verification logs nothing at all. The error is placed into the Gatekeeper response (results[idx].Error = err.Error()) but never written to the pod log, so no valid executor configured, a registry auth failure, or a signature failure leaves no trace on the server side.
• Both HTTP handlers discarded the error from verify/mutate (_ = s.verify(...)), so a body read, unmarshal or response-encoding failure produced an empty response and no log either.

Change

Trace IDs — attach a generated trace ID to each verify/mutate request context via logger.InitContext. It propagates to all context-aware downstream logging (executor, verifiers, auth providers, policy providers), so a single request's logs correlate.

Reading the trace ID from an incoming request header is supported by internal/logger but requires InitLogConfig to register the header names, which this binary does not call today. That can be wired up in a follow-up.

Request logging in internal/httpserver/handlers.go, all through the request-scoped logger so entries carry the trace ID and component-type:

• error — verification failures, reference parse/resolve failures, and the handler-level errors that were previously discarded.
• info — the per-artifact verification outcome, the key operational/audit signal (v1 logged the same). The message leads with succeeded=<bool> so a violation is greppable without parsing the JSON report. It runs once per artifact per request, whether the result was served from cache, recomputed, or shared via singleflight — it previously sat inside the singleflight closure, so a cache hit logged nothing and so did any caller deduplicated into another in-flight request.
• debug — request start (artifact/reference count), cache hit/miss, resolved reference, and request duration.

System-error metric — count handler/processing failures with metrics.ReportSystemError, using stable, low-cardinality category labels (verify_artifact, mutate_parse_reference, mutate_resolve_reference) rather than the error text, so Prometheus label cardinality stays bounded. The full error is still returned to the caller and written to the log.

Example output that previously did not exist at all:

level=error msg="failed to handle the verification request: failed to unmarshal request body to provider request: ..." component-type=server trace-id=0d9a6926-d465-4a19-8217-8ce77b7c5484
level=error msg="failed to verify artifact1: no valid executor configured" component-type=server
level=info msg="verification result for registry.example/app:v1: succeeded=false, report={...}" component-type=server

This is deliberately scoped to the HTTP request path. Adding debug logging inside internal/executor, the verifiers and the stores (also currently at zero) is a sensible follow-up — see #2876 and #2877 for the credential/Key Vault half.

Testing

• TestVerify_LogsFailures and TestResolveReference_LogsFailures assert the failure paths actually emit an error entry, so this can't silently regress. Assertions match on the test's own message via a shared findEntry helper rather than on log level alone, so a global hook cannot make them pass spuriously.
• TestVerifyHandler_LogsFailure / TestMutateHandler_LogsFailure cover the previously discarded handler errors and assert the entry carries a trace ID.
• TestVerify_LogsOutcomeOnCacheHit covers the warm-cache path; TestLogVerificationResult_Violation covers the violation message format.
• go build ./..., go vet, package tests and golangci-lint pass. No go.mod change (logrus/hooks/test ships with logrus). ReportSystemError is nil-guarded, so it is a no-op when metrics are disabled.

Enable the debug logs with --set logger.level=debug (#2846).